Microsoft® Exchange is a messaging and collaboration software system that provides a variety of applications for group interaction using networked computer systems. Specifically, Microsoft Exchange (by Microsoft Corp. of Redmond, Wash.) provides support for electronic mail (e-mail) over various networks. Specifically, the Exchange software provides an e-mail server to support remotely connected e-mail clients such as, e.g., Microsoft Outlook®. The Exchange software acts as a server for providing various functionalities to clients. An Exchange server can run on a variety of operating systems including, for example, the Microsoft Windows NT® or Microsoft Windows® 2000 operating systems.
In a typical configuration, Microsoft Exchange stores data associated with e-mail services in a series of three databases. In the particular example of Microsoft Exchange version 5.5, these three databases are named priv.edb, pub.edb and dir.edb. However, it is contemplated that other versions support different database structures. The default storage locations for these databases are on a disk locally connected to the computer on which the Exchange software is running. Specifically, the priv.edb file stores the actual e-mail messages received by the Exchange server. The pub.edb file tracks and stores the public folders associated with the electronic mail messages. The dir.edb file holds the topology of the various folders.
FIG. 1 shows a flow chart of an exemplary e-mail passing through an Exchange server. In step 105, the electronic mail is received via known e-mail processes. These processes can include the use of such protocols as the post office protocol (POP). Next, in step 110, the message is stored in the memory of the server. The storage of the message in memory is often transient in nature until the message is committed to some form on nonvolatile storage. The e-mail message is then written to a log file in step 115. The log files typically have a preallocated size. In one known example, each log file is 5 megabytes (MB) in size. Thus, an Exchange server may have a variable number of log files at any given point-in-time, depending on how many log files have been incorporated into the database files. Next, the log files are written to and incorporated into the database files, in step 120. The writing of the log file to database occurs in a lazy write fashion. By “lazy write” it is meant a writing process or procedure of the Exchange software that performs the write when central processing unit cycles are available. Thus, this lazy write proceeds mainly during off-peak times when the server is not being heavily utilized.
FIG. 2 is a schematic block diagram of an exemplary Exchange server environment 200. An exemplary server 205 executing the Microsoft NT operating system containing a local disk 210 is shown connected to a tape drive 220 and an external disk 215. The external tape drive 220 is connected via either a small computer system interface (SCSI) connection or a switching network, such as storage area network (SAN). Similarly, the external disks 215 may be connected via a SAN or other suitable networking architectures. The Exchange server 205 may be incorporated into a Microsoft Clustering System (MSCS) environment 225. Such a clustering environment provides for redundant data program access to clients.
In known examples of Exchange servers, the Exchange software provides an application program interface (API) that is accessible by other programs executing on the server for performing backup and restore operations on the various databases. Other applications or processes executing on the server can access these APIs to perform various backup/restore operations. These API's are targeted toward the use of tape drive as a backup storage device. Such backup operations are normally performed while the Exchange server is operating. As tape drives typically have a slower read/write time than disk drives, the backup of databases with a tape device can consume a significant amount of time. While the Exchange server is still operational during a backup operation, performance is degraded during the course of the backup operation. Due to the extended degradation caused by the use of tape devices a backup storage media, backups are typically performed at night (or other off-peak time), when few users are utilizing the system. Similarly, a restore operation using a tape device consumes a substantial amount of time to restore the databases. When performing a backup or restore operation, the database files and any unincorporated log need to be saved and/or restored. Thus as the size of the various database files increases, the time required to perform a backup/restore operation to a tape device also increases.
In a further known example, the Exchange server is adapted to have the database and log files preferably written to a local disk. However, by utilizing other software products such as, e.g. SnapManager® Data Migrator available from Network Appliance, Inc. of Sunnyvale, Calif., the log files and databases may be written to disks that are remotely connected to Exchange server. In one known implementation, the Exchange server is operatively interconnected with a file server and associated disk arrays, which provides file service for storage and access of the database and log files.
A file server is a computer that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. By “file system” it is meant generally a structuring of data and metadata on a storage device, such as disks, which permits reading/writing of data on those disks. A file system also includes mechanisms for performing these operations. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a specially-formatted file in which information about other files and directories are stored. A filer may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
A common type of file system is a “write in-place” file system, an example of which is the conventional Berkeley fast file system. In a write in-place file system, the locations of the data structures, such as inodes and data blocks, on disk are typically fixed. An inode is a data structure used to store information, such as meta-data, about a file, whereas the data blocks are structures used to store the actual data for the file. The information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, file type and references to locations on disk of the data blocks for the file. The references to the locations of the file data are provided by pointers, which may further reference indirect blocks that, in turn, reference the data blocks, depending upon the quantity of data in the file. Changes to the inodes and data blocks are made “in-place” in accordance with the write in-place file system. If an update to a file extends the quantity of data for the file, an additional data block is allocated and the appropriate inode is updated to reference that data block.
Another type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block on disk is retrieved (read) from disk into memory and “dirtied” with new data, the data block is stored (written) to a new location on disk to thereby optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. A particular example of a write-anywhere file system that is configured to operate on a filer is the Write Anywhere File Layout (WAFL™) file system also available from Network Appliance, Inc. of Sunnyvale, Calif. The WAFL™ file system is implemented within a microkernel as part of the overall protocol stack of the filer and associated disk storage. This microkernel is supplied as part of Network Appliance's Data ONTAP™ storage operating system, residing on the filer, that processes file-service requests from network-attached clients.
As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a storage system that implements file system semantics and manages data access. In this sense, Data ONTAP™ software is an example of such a storage operating system implemented as a microkernel. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
Disk storage is typically implemented as one or more storage “volumes” that comprise physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof, volume and file system shall generally be used synonymously. The disks within a volume are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data. In the example of a WAFL-based file system, a RAID 4 implementation is advantageously employed. This implementation specifically entails the striping of data across a group of disks, and separate parity caching within a selected disk of the RAID group. As described herein, a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity) partitions in a single disk) arranged according to a RAID 4, or equivalent high-reliability, implementation.
A file server, as described above may be interconnected by a network to an Exchange or other database server to provide file service operations. In the example of an Exchange database server, the various database files can be stored on a set of disks interconnected with a file server through the use of such software programs as the above-described SnapManager software. As noted, such file servers typically utilize a tape device for backup/restore operations. A substantial amount of time is required to perform a backup operation to a tape device. Consequently, many system administrators do not frequently perform backup operations, thus preventing system performance degradation due to the ongoing backup operation. To restore a database to a particular point-in-time, the administrator typically requires a backup of the file system or database files generated at the desired point-in-time. As backups are typically written to tape devices with lengthy intervals between successive backups, the possible selection of discrete points-in-time to restore to is generally limited.